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© System and method for emulating a window management environment having a uniform windowing 
interface. 



© An X window display server provides a virtual 
window manager client that, from the viewpoint of 
client programs connected to the server, is indistin- 



guishable from a real window manager client. The 
emulated window manager is implemented as an 
internal server client. 
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BACKGROUND OF THE INVENTION 

This invention relates generally to systems for 
providing graphics environments for application 
programs, and more particularly to common win- 
dow management interfaces for systems capable of 
running multiple application programs written for 
various environments. 

In modern data processing, protocols allow ap- 
plication programs to communicate with system 
components such as I/O devices or servers. These 
protocols include application programming inter- 
faces, interprocess communication protocols, and 
remote procedure calls. With the rapid growth of 
computers and application programs, there has 
been a parallel growth in the number of software 
and hardware protocols. The existence of multiple 
protocols throughout the data processing industry 
has been a source of inconvenience because ap- 
plication programs written for one protocol must be 
modified, rewritten, or even redesigned, for a dif- 
ferent protocol. 

The problem of multiple protocols is particu- 
larly acute in the graphics area where there are a 
number of standards in use. Certain graphics sys- 
tems use a software package called a display serv- 
er to implement a graphics protocol. In such sys- 
tems, application programs requesting graphics 
services, called clients, send their graphics re- 
quests to the display server. 

The graphic services can include window man- 
agement. Windows are areas on a video screen 
that allow a user to view data processing output. 
Windows also give application programs an or- 
ganized way of managing the use of space on the 
screen, and allow the display server to present 
information for multiple application programs in an 
organized way. If clients want windows, another 
software package called a "window manager" is 
generally used to control certain window manage- 
ment functions. 

By using a window manager, individual clients 
need not be concerned with window management 
functions, such as the positioning and sizing of 
windows. An example of a graphics system having 
a window manager common to a number of clients 
is one defined by the X Window System protocol, a 
standard developed at the Massachusetts Institute 
of Technology. Fig. 1 shows an X Window system, 
where client 110, 120, and 130 send graphics re- 
quest to X display server 140, thereby commu- 
nicating with graphics hardware 150. Client 130 is a 
window manager that can provide window manage- 
ment functions to both clients 1 1 0 and 1 20. 

Basic principles and architecture of the X Win- 
dow system may be found in "Introduction to the X 
Window system" by Oliver Jones, Prentice-Hall 
1989. The protocol for communicating with an X 



Window display server is described in "X Window 
system Protocol MIT X Consortium Standard X 
Version 11," Release 4, by Robert W. Scheifler, 
MIT Laboratory for Computer Science. Conventions 

5 for communicating with the window manager, and 
with other clients, are described in "Inter-Client 
Communication Conventions Manual, Version 1.0, 
MIT X Consortium Standard," by David S.H. 
Rosenthal, Sun Microsystems, Inc. 

w X Window systems are not the only graphics 
systems in use throughout the industry. Therefore, 
it may be necessary to execute clients written for 
an X Window System together with clients written 
for some other type of windowing system on a 

75 common set of graphics hardware. For purposes of 
the discussion that follows, the other type of win- 
dowing system will be referred to generically as a 
"host system." 

One proposal for providing window manage- 

20 ment functions for a data processing system run- 
ning both clients using the X Window System pro- 
tocol ("X clients") and clients using the host sys- 
tem protocol ("host clients") is shown in Fig. 2. Fig. 
2 shows a unified window system 200 serving both 

25 X display server clients 210 and 220 and host 
server clients 230, 240 and 250. A common win- 
dow manager 260 is provided to present a uniform 
window interface to the user. An X server front end 
270 implementing the X display server shares 

30 common support functions 290 (conventions, code, 
data structures, hardware access structures, etc.) 
with a host server front end 280 implementing the 
host server, thereby allowing hardware resources to 
be harmoniously allocated. 

35 System 200, however, has several disadvan- 
tages. First it requires writing both an X display 
server front end and a host server front end. Sec- 
ond, it is not easy to build system 200 from exist- 
ing host systems because of the many modifica- 

40 tions required. 

Fig. 3 is an example of an existing host system 
300 which supports host system clients 310, 320, 
and 330. System 300 also includes a host server 
340, including an internal window manager, to pro- 

45 vide graphics functions to host system clients 310, 
320 and 330. 

Converting system 300 of Fig. 3 into system 
200 shown in Fig. 2 presents both legal and tech- 
nological problems. For example, the person at- 

50 tempting to implement the X display server in 
system 300 might not possess the legal right to 
modify the support technology used in the host 
server 340. Also, the support technology of the 
host server may be poorly documented or struc- 

55 tured in such a way as to make it difficult or 
impossible to adapt to support another server. 
Therefore, it is desirable not to have to modify 
existing host systems. 
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Fig. 4 shows another proposal to solve the X- 
server/host system integration problem. In system 
400 shown in Fig. 4, host clients 410, 420, and 430 
of the host system are connected to a host server 
440 that includes window management functions. 
Another host client 450 is an X display server that 
operates by translating X protocol to host protocol. 
X clients 460 and 470, which are written with the X 
protocol, are coupled to client 450 and thus can 
run using the graphics hardware 490 attached to 
host server 340 as host clients 410, 420 and 430 
do. 

In an X Window System, the common window 
manager is the window manager client. This win- 
dow manager client is connected to the X display 
server, as are X clients. Clients send requests to 
the X display server to effect graphics operations. 
Certain requests sent from X clients to the X dis- 
play server are redirected by the X display server 
to the window manager client. The window man- 
ager client then processes the request, and may 
then send a request to the X display server. Other 
certain requests sent from X clients to the X dis- 
play server are processed by the X display server 
and notification is sent to the window manager 
client. 

When using the different types of clients in a 
single system as described above, it is desirable to 
present a user with a uniform user interface. One 
way to achieve this would be to tailor the window 
manager 480 of the X type system to have the 
window interface of the host system. One dis- 
advantage of system 400 is that the process re- 
sponsible for starting window manager 480 would 
need to have knowledge of the type of host system 
in order to allow it to select a manager having the 
window interface of the host system. If the host 
system changes, a new window manager 480 is 
required. This is a problem because the process 
starting the window manager may exist on a net- 
work node separate from the host system, where it 
may be difficult to obtain knowledge of the type of 
host system. The separation of window manager 
480 from X server 450 can make it difficult to track 
changes to the host system. 

SUMMARY AND OBJECTS OF THE INVENTION 

It is therefore an object of this invention to 
provide a display server that can be implemented 
using the support technology of another server. 

It is a further object of this invention to allow 
clients written with various types of protocols to run 
together on one set of graphics hardware. 

It is still a further object of this invention for the 
window management interface presented to the 
user to be consistent between clients written with 
the various protocols. 



Briefly, this invention emulates a window man- 
agement structure in a display server. This ensures 
that there will always be an appropriate window 
manager for the clients that will present a uniform 

5 window interface to the user. 

To achieve these and other objects of the 
present invention, in a computer system having a 
display server to provide centralized display func- 
tions to a client, a method of responding to a 

w request for graphics operations generated by the 
client, the request including at least one function, 
comprises the steps, executed by the display serv- 
er, of receiving a request for a graphics operation 
from the client; determining whether the graphics 

75 operation request requires performance of window 
management functions; submitting the graphics op- 
eration request to an emulated window manage- 
ment structure in the display server to perform any 
window management functions required by the 

20 graphics operation request; and executing the func- 
tions in the graphics operation request directly 
which do not require window management func- 
tions. 

According to another aspect of the invention, A 

25 computer system for providing centralized window- 
ing mechanisms to clients comprises a display; 
client processor means for executing the clients 
which generate requests for graphics operations to 
be implemented on the display; and server proces- 

30 sor means, coupled to the display and to the client 
processor means, for responding to the graphics 
operation requests generated by clients. The server 
processor means includes an emulated manage- 
ment structure for providing window management 

35 functions, means for receiving the graphics opera- 
tion requests for graphics operations from the cli- 
ents, means, coupled to the receiving means, for 
determining whether the graphics operation re- 
quests for graphics operations requires perfor- 

40 mance of window management functions, means, 
coupled to the receiving means and to the deter- 
mining means, for directly executing the functions 
of the graphics operation requests which do not 
require window management functions, and means, 

45 coupled to the receiving means and to the deter- 
mining means, for submitting to the emulated man- 
agement structure the functions of the graphics 
operation requests which do require window man- 
agement functions. 

50 The accompanying drawings, which are incor- 
porated in and which constitute a part of this speci- 
fication, illustrate one embodiment of the invention 
and, together with the description, explain the prin- 
ciples of the invention. 

55 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 shows a diagram of a prior art X Window 
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graphics system. 

Fig. 2 shows a diagram of a proposed unified 
multiserver graphics system. 

Fig. 3 shows a diagram of a prior art single 
server graphics and window management system. 

Fig. 4 shows a diagram of a X Window graph- 
ics system layered over a host graphics system. 

Fig. 5 shows a diagram of the elements of 
graphics system according to a preferred embodi- 
ment of the present invention. 

Fig. 6 shows a diagram of the window hierar- 
chy according to a preferred embodiment of the 
present invention. 

Fig. 7 shows a typical internal window data 
structure according to a preferred embodiment of 
the present invention. 

Fig. 8 shows on X window tree using instances 
of the window data structure shown in Fig. 7. 

Fig. 9 shows a general control flow diagram for 
a preferred implementation of a window manage- 
ment method in accordance with a preferred em- 
bodiment of the present invention. 

Fig. 10 shows a control flow diagram for a 
CreateWindow request. 

Fig. 11 shows some substeps of the control 
flow outlined in Fig. 9. 

Fig. 12 shows a control flow diagram for 
changes to Reparentwindow request processing. 

Fig. 13 shows a control flow diagram for a 
ChangeBorderWindow routine in a ConfigureWin- 
dow request. 

Fig. 14 shows a control flow diagram for 
changes to the routine MoveWindow for the Con- 
figureWindow request. 

Fig. 1 5 shows a control flow diagram for a PM 
WM_MOVEWINDOW event. 

Fig. 1 6 shows a control flow diagram for a PM 
WM MINMAXFRAME event. 

Fig. 17 shows a control flow diagram for a PM 
WM_SETFOCUS event. 

DESCRIPTION OF THE PREFERRED EMBODI- 
MENT 

Reference will now be made in detail to a 
presently preferred embodiment of the invention, 
an example of which is illustrated in the accom- 
panying drawings. 

Fig. 5 shows a preferred embodiment of the 
data processing system of this invention. A data 
processing system 500 includes a host server 510, 
coupled to graphics hardware 520 via drivers 515, 
to provide window management services to host 
clients 522, 525, and 527. 

Display 530, which is also coupled to host 
server 510, preferably implements the X Window 
System protocol. Although display server 530 is 
configured using X Window System protocol, the 



invention can be practiced with any graphics sys- 
tem having a common window manager recon- 
figurable separate from the server. 

The implementation of display server 530 as a 

5 client of host server 510 is not described in detail 
because it is believed that an acceptable imple- 
mentation can be designed by persons of ordinary 
skill having knowledge of both servers. For exam- 
ple, other X servers that communicate with the 

w display through a host server have been designed, 
including XVision, a Microsoft Windows-based X 
server, marketed by Visionware Limited; and MacX, 
an Apple Macintosh-based X server. 

In the preferred embodiment of the present 

75 invention, the presence and functionality of an X 
window manager client (WMCLIENT) 540 is emu- 
lated within the X display server 530. This emula- 
tion is invisible to X clients 533 and 538 which 
cannot detect whether they are running in a con- 

20 ventional X Window System or in an X Window 
System according to the preferred embodiment of 
the present invention where the WMCLIENT 540 is 
emulated within the display server 530. The display 
server 530 in this case supplies a virtual window 

25 manager to the operating environment of the X 
clients. 

In a preferred embodiment, the host server 51 0 
is the Microsoft Operating System/2 Presentation 
Manager (PM). The host server 510, however, is 
30 not restricted to the PM, and in fact could be any 
graphics system having sufficient functionality to 
support the protocol of the system being imple- 
mented, which is the X Window System in the 
preferred embodiment. 

A. Overview of Server/Window manager Functional- 
ity 

X window clients send "requests" to the X 

40 window server to perform graphics functions. A 
request is a type of message. For example, the 
CreateWindow request designates that a new win- 
dow be created. 

The X Window server, in turn generates 

45 "events" to inform clients of the status of a win- 
dow. For example, the CreateNotify event indicates 
that a certain window has been created. When the 
CreateNotify event is generated for a window, it is 
sent to clients that have designated CreateNotify as 

so one of the events they wish to receive for that 
window, by setting an appropriate bit in an event 
mask for that window's parent. 

Fig. 6 includes a diagram 600 of a window 
hierarchy implemented according to the preferred 

55 embodiment of the present invention. In the X 
window System, a window is the child of a single 
parent window. All client-created windows are de- 
scended from a common X root window, shown as 
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X_ROOT 601 in Fig. 6. In the preferred embodi- 
ment the X root window X_ROOT 601 is also the 
host system root window, shown as HWS_ROOT 
602 in Fig. 6. 

In the X Window System, a window is owned 
by a single client that creates the window by is- 
suing a CreateWindow request. 

The functionality of window manager client 
(WMCLIENT) 540 will now be described with refer- 
ence to Fig. 6, which shows an X window tree after 
the X window server has processed a number of 
CreateWindow requests. A Child of the root window 
that is designated to be window-managed (by cre- 
ating the window without an override-redirect at- 
tribute) may be created by an X client. For exam- 
ple, windows A 610, B 620, C 630, D 640 and E 
650 in Fig. 6 were each created as children of the 
root windows. 

From a user client point of view, when the 
client makes a request of server 530 to create a 
window managed window, for example window A 
61 0, the window is created as a child of the X root 
window. After that, WMCLIENT 540 creates a cor- 
responding window, for example window WM1 605 
in Fig. 7 and "reparents" window A 610 to be the 
child of WM1 605. The WMCLIENT 540 then gen- 
erates a ReparentNotify event for window A 605, 
thereby informing clients of the reparenting of the 
window. 

Thereafter, when a client, such as X client 533 
in Fig. 5, makes a request of display server 530 in 
Fig. 5 to map (make visible) a window managed 
window, for example window A 610, the request is 
redirected to WMCLIENT 540 which then makes a 
request to map both window A 610 and WM1 605. 
UnmapWindow and DestroyWindow requests are 
also directed to WMCLIENT 540. 

Similar to the operation of a real window man- 
ager, such as window manager 330 in Fig. 3, the 
virtual window manager WMCLIENT 540 of the 
preferred embodiment does not interfere with the 
creation, mapping, unmapping, or destroying of a 
window that a client does not wish to be window 
managed. A client in this case creates the window 
with the override-redirect attribute in the 
CreateWindow request. For example, windows F 
660 and Z 680 were created with the override- 
redirect attribute. Regardless of the override-re- 
direct attribute, WMCLIENT 540 does not interfere 
with request processing of windows that were not 
created as the child of the X root window 
X_ROOT 601 . Thus, for example windows a 61 1 , 
b 612, d 613, e 614, f 615, g 616, h 617, i 618 and 
y 619 were not created as the child of X root 
window X_ROOT 601. Therefore they will not be 
managed. 

B. Overview of Server/Window Manager Client Ar- 



chitecture 



A preferred embodiment for the display server 
530 containing WMCLIENT 540 is a modified ver- 

5 sion of the X Window System sample server Ver- 
sion 11, Release 4, published by MIT, and the 
Microsoft operating System/2 Presentation Man- 
ager (PM) graphics system. The modifications to 
the server are needed to emulate a window man- 

w ager. Thus, display server 530 differs from the X 
window sample server in both data structure and 
control flow. For example, the sample server has 
calls to a device dependent layer (DDX). In display 
server 530, routines of the DDX layer contain calls 

75 to PM. 

In the preferred embodiment of the invention 
shown in Fig. 5, the host server 510, has internal 
window management functions. WMCLIENT 540 
takes advantage of this implementation of window 

20 management functions inside of the host server 
510 by delegating window management functions 
to host server 510. This delegation has two princi- 
pal advantages. First, WMCLIENT 540 can supply 
window management functions to X clients without 

25 implementing those functions within WMCLIENT 
540 itself. Second, X client managed windows in- 
herit the windowing interface of the PM system so 
that X clients will have a common window interface 
with host clients ("PM clients"). 

30 With regard to the first advantage, windows 
WM1 605, WM2 615, WM3 625, WM4 635, and 
WM5 645 in Fig. 6 are created as "PM frame" 
windows in server 510. PM frame windows contain 
various standard user interface objects such as 

35 buttons and menus, which a user can manipulate to 
perform functions such as moving a window. 
WMCLIENT 540 need not have knowledge of or 
capability to generate these user interface objects, 
and need only he concerned with the results of the 

40 user's manipulation of these objects. As explained 
below, WMCLIENT 540 learns of the results of a 
user's manipulation of these objects by receiving 
PM events. For example, a user may select a 
button to move a window, resulting in WMCLIENT 

45 540 receiving a PM move window event, 
WM_MOVE. 

An additional advantage of delegating window 
management to server 510 is that, if the host 
system interface were to change, the X window 

so interface provided by WMCLIENT 540 would tend 
to remain compatible with the host system inter- 
face without having to be modified. 

C. Data Structure Differences 

55 

WMCLIENT 540 must have knowledge of win- 
dows being created destroyed, mapped, or unmap- 
ped. This knowledge is necessary because, for 
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example, when a window managed X window is 
unmapped (i.e., removed from visibility), the frame 
window must also be unmapped. 

In order for WMCLIENT 540 to keep track of 
windows, certain X system data structures must be 
modified. Fig. 7 shows an X WindowRec window 
data structure 700 modified for use in a preferred 
embodiment of this invention. Portion 710 has iden- 
tifiers from the standard part of the X Window 
System. Identifiers 720 and 730 are identifiers ad- 
ded to the set of WindowRec identifiers to imple- 
ment the preferred embodiment of the present in- 
vention. HASBEENMAPPED identifier 720 controls 
the suppression of PM 

WM_WINDOWPOSCHANGED and WM_MOVE 
events which host server 51 0 may generate prema- 
turely. 

hPMWnd identifier 730 is a pointer to a PM 
window structure corresponding to the X window 
structure. Because every X window is implemented 
as a PM window, this pointer allows a translation 
from X window to corresponding PM window, which 
is needed for the processing of requests. 

In addition the PM window data structures 
(PMREC) must be modified to contain a pointer to 
the corresponding X WindowRec data structures. 
This pointer allows a translation from PM window to 
the corresponding X window, which is needed for 
the processing of PM events. Processing PM 
events by display server 530 may involve the gen- 
eration of X events. 

The various X WindowRec data structures are 
linked together to form an X window tree which 
allows display server 530 to find related windows. 
Fig. 8 shows a diagram mapping X windows repre- 
sented by X WindowRec data structures 801 , 803, 
805 into the corresponding PM windows repre- 
sented by PMREC structures 802, 804, 806. The 
hPMWnd identifiers in structures 801, 803 and 805 
point to corresponding PMRECs 802, 804 and 806, 
respectively which also point back to the corre- 
sponding X WindowRec . 

In the preferred embodiment, the correspon- 
dence allows X display server 530 to receive a 
request for an X window and then issue a PM 
request for the corresponding PM window. 

D. Control Flow Differences 

Although the virtual window manager 
WMCLIENT 540 (Fig. 5) appears to be a separate 
process from display server 530 when viewed out- 
side of display server 530, in the preferred embodi- 
ment, display server 530 and WMCLIENT 540 
share a common address space within a common 
process. 

Further, to achieve certain efficiencies, the 
code implementing WMCLIENT 540 is intertwined 



with the code implementing the other portions of 
display server 530. In other words, WMCLIENT 540 
is a procedure composed of a first set of inter- 
related computer instructions, and the part of dis- 

5 play server 530 responsible for executing the 
graphics operation request directly is a second 
procedure composed of a second set of inter- 
related computer instructions interspersed with the 
computer instructions of WMCLIENT 540. Because 

w the two sets of computer instructions are inter- 
spersed, execution of the two procedures is inter- 
leaved. 

As described previously, the invention includes 
the steps of receiving a graphics request from a 

75 client, such as X client 533, and submitting the 
request to an emulated management client, such 
as WMCLIENT 540. In the preferred embodiment, 
of the emulated management client, WMCLIENT 
540, is implemented with conditional statements 

20 dispersed throughout the X window sample server. 
For example, if the request being processed re- 
quires redirection, supplemental calls to request 
dispatch routines are performed inline. This has the 
effect of simulating the requests that a window 

25 manager would submit in response to receiving a 
redirected request. 

Code to be added to an X window sample 
server in order to implement WMCLIENT 540 will 
be discussed. Unless otherwise specified, routine 

30 names used in the discussion that follows refer to 
routines in the X window sample server version 11, 
Release 4, published by MIT. All OS/2 PM routine 
names are identified by "PM." 

35 1. Initialization 

All PM clients require that the entry point be 
named MAIN. Therefore, one modification to the X 
window sample server is to rename the entry point 

40 named MAIN to be XMAIN, and modify it. A new 
routine, MAIN, is written to initialize the PM envi- 
ronment, and then MAIN calls XMAIN. This in- 
itialisation includes a call to PM WinRegisterClass 
to register a PM window class. This PM call causes 

45 extra storage in the PM window data structure 
(PMREC) to be allocated for the pointer to a cor- 
responding X WindowRec data structure. Because 
XMAIN may return when server 530 closes down, 
MAIN closes down the PM environment after the 

so call to XMAIN. 

From the viewpoint of clients, the virtual win- 
dow manager client WMCLIENT 540 must appear 
to be just another client connected to the server 
and possessing resources such as windows. To 

55 achieve this end, the status of WMCLIENT 540 is 
represented in display server 530 with many of the 
same data structures that would be used to repre- 
sent other X clients. This representation is imple- 
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merited with steps performed in the initialization 
section of the sample server where display server 
530 allocates data for WMCLIENT 540. The data 
initialization for WMCLIENT 540 is performed after 
the "server client," which owns certain resources 
including the root window, is created and initialized. 

The data initialization for WMCLIENT 540 in- 
cludes allocating a data structure (not shown) for 
the client and placing the data structure at a 
predefined position in display server 530's client 
array. InitClientResources is called for WMCLIENT 
so that space is allocated in the client resources 
table for resources such as windows, fonts, pix- 
maps, and graphics contexts. A client counter (not 
shown) in Display server 530 is increased by 1 to 
signify the existence of WMCLIENT 540. 

In the routine CreateRootWindow, PM Win- 
CreateWindow is called to create a PM object 
window, shown X_ROOT 601 in Fig. 6, which is 
equivalent to MWS_ROOT 602. (The PM object 
window is a special PM window, having no parent, 
that will own the PM frame windows) The display 
server 530 owned X root window is associated with 
the PM root window by setting the X WindowRec 
structure to point to the PM root window: 

pWin-hPMWnd = HWND DESKTOP. 

WMCLIENT 540 makes itself eligible to receive 
certain events in which a window manager would 
be interested, by setting an event mask for the X 
root window: pwin-*eventMask = ResizeRedirect- 
Mask | SubstructureRedirectMask. Because only 
one client can set the ResizeRedirectMask and 
SubstructureRedirectMask fields in an event mask 
for a certain window, WMCLIENT 540's setting 
these fields in a root window event mask prevents 
another window manager from providing common 
management functions for all clients. 

2. Request Processing 

Fig. 9 shows a general flow diagram 900 for 
request processing in the preferred embodiment. 
First, a request for graphics operation is received 
by display server 530 from an X client (step 910). 
Next, display server 530 determines whether the 
request requires performance of window manage- 
ment functions (step 920). This determination, dis- 
cussed in greater detail below, generally involves a 
test of the status of the window to which the 
request relates. If the request does not require 
window management functions, then it is executed 
as dictated by the request (step 930). If the request 
does require window management functions, the 
request is submitted to the emulated manager 
WMCLIENT 540 (step 940). In the preferred em- 
bodiment, the step of submitting (step 940) is im- 
plemented by following WMCLIENT 540 execution 
path, which exists in the same address space as 



the execution path of the executing step (step 930). 

For certain requests, the invention allows for 
the step of submitting (step 940) to include the 
substep of executing the request directly, as dic- 

5 tated by the request, before submitting the request 
to the emulated manager. 

Steps 920, 930 and 940 will now be described 
in greater detail in the discussion of the implemen- 
tation of specific requests. 

w Fig. 10 shows a flow chart 1000 for handling 
the CreateWindow request. First a new WindowRec 
structure is allocated for the window to be created 
(step 1010). If the new window is the root window 
(step 1015) normal processing is avoided because 

75 the X root window has been created and is owned 
by the server client. 

Next a determination is made to see whether 
management functions are required (step 1017). 
This is essentially the determination made in step 

20 920 of Fig. 9. In order to determine whether the 
request requires window management, a check is 
performed to see whether the window is to be 
created as child of root window and without the 
override-redirect attribute. If both conditions are 

25 true, the CreateWindow request is for a window to 
be managed. If either condition is false, the request 
is treated as if it were for a nonmanaged window, 
as in step 930 in Fig. 9. 

The first step in responding to a request from a 

30 nonmanaged window involves translating the co- 
ordinates of the window to be created from X 
coordinates to PM coordinates (step 1020). This 
translation is necessary because in the X Window 
System the origin of a window is the upper lefthand 

35 corner, while in the PM window system the origin 
of a window is the lower lefthand corner. Next, a 
PM window without user interface objects 
(PMREC) is created (step 1025). A pointer to an X 
WindowRec is then saved in the PMREC just cre- 

40 ated (step 1030), and a pointer to the PMREC is 
saved in the X WindowRec (step 1035), thus creat- 
ing an addition to an X window tree, such as the 
one shown in Fig. 8. Finally, a CreateNotify event is 
generated to inform clients of the creation of a new 

45 window (step 1040). 

If the CreateWindow request does require win- 
dow management function (step 1017), the right- 
most branch of the flowchart 1000 beginning with 
step 1050 is followed. Steps 1050-1095 correspond 

so to the emulation of a window manager inside of the 
display server and receiving windowing requests 
from the emulated manager as in step 940 of Fig. 

The emulation begins with the calculation of an 
55 X window origin to the WMCLIENT 540 parent of 
the requested window to be created. This calcula- 
tion is based on the requested window's width, 
height, and border size (step 1050). It also involves 
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translation of X coordinates to PM coordinates. 
Next, the origin of the PM frame window relative to 
the PM root window is calculated such that all, or 
as much as possible, of the PM frame window is 
visible on the screen (step 1055). Next, both the 
requested and the PM frame windows are created 
(step 1060). Preferably this window creation uses a 
call to PM WinCreateStdWindow to create a frame 
window using a style that includes a title bar, 
system menu, size border, and the minimum and 
maximum control features. 

After the call to WinCreateStdWindow, the sta- 
tus of the newly created requested and frame win- 
dows is updated (step 1070). This preferably in- 
volves four calls to PM routines. The first is a call 
to PM WinSetWindowULong to save a pointer to 
the newly allocated WindowRec structure of the 
requested window in PM window structure. Next a 
call to WinSetWindowPos is made to set the posi- 
tion and size of the frame window. Then a call is 
made to PM WinSetOwner to set the owner of the 
frame window to be the PM object window 
X_ROOT 601, described earlier. Finally, a call is 
made to PM WinSetOwner to set owner of the 
requested window newly created to be the frame 
window newly created. 

After updating the window status, the hpMWnd 
field of the WindowRec data structure of the re- 
quested window is set to point to the new PMREC 
(step 1080). This is done so that X display server 
530 and WMCLIENT 540 can process subsequent 
requests for the new X window by processing the 
corresponding PM window. 

Next, a CreateNotify event is generated (step 
1090), as required by the X protocol. Finally, an X 
window corresponding to the newly-created PM 
frame window is created as a parent of the newly 
created X window (step 1095). This completes the 
management of the CreateWindow request per- 
formed by WMCLIENT 540. 

Fig. 1 1 shows a flow diagram 1 1 00 to explain a 
preferred method for creating the X window as a 
parent (step 1095). To create an X window as 
parent, first a new X WindowRec data structure is 
allocated for the PM frame window just created 
(step 1110). 

The X WindowRec structure is then initialized 
(step 1 1 20). This is preferably accomplished in two 
steps. First, a client part of the ID field of the 
DrawableRec structure, shown in portion 710 (Fig. 
7), is set to "1 " to indicate that WMCLIENT 540 is 
the owner of the window. Then the X WindowRec 
parent field is set to indicate that the root window is 
the parent. 

The requested window is then removed from 
its sibling chain (step 1 1 30) because the requested 
window will no longer be a sibling to the child of 
root windows after the reparenting. 



Next, the X window just created, owned by 
WMCLIENT 540 and corresponding to the new PM 
frame window, is inserted as a child of the X root 
window. This new X window is placed at the top of 
5 the stacking order of the children of the root win- 
dow, and the requested window is inserted as child 
of the WMCLIENT 540 owned X window (step 
1140). 

The PM window status is then updated (step 

w 1150). This is preferably accomplished by calling 
PM WinSetWindowULong to save the pointer to the 
WMCLIENT X WindowRec structure in a PMREC. 

Following the PM window adjustment, the X 
WindowRec structure is updated (step 1160). In the 

75 preferred embodiment, this is done by setting the 
hPMWnd field of the X WindowRec structure with 
the pointer to the PMREC for the frame window. 

Next, a routine AddResource is invoked for the 
newly-created window, so that the window will be 

20 recorded as a system resource (step 1170). Finally, 
a ReparentNotify event is generated for the window 
as required by the X protocol (step 1180). 

A ReparentNotify event is also generated by 
the ReparentWindow request. A ReparentWindow 

25 request may involve a change in the window man- 
agement status of the requested window, causing 
an unmanaged window to become managed or a 
managed window to become unmanaged. Fig. 12 
includes a flow diagram 1200 of a procedure to 

30 make additions needed to the routine ReparentWin- 
dow. The standard sample server code that makes 
the requested window a child of the parent speci- 
fied in the ReparentWindow request is not shown. 
For purposes of ReparentWindow request pro- 

35 cessing, a window is one of three types: 1) 
POPUP, meaning that the window has the override- 
redirect attribute and is child of the root; 2) WIN- 
DOWMANAGED, meaning that the requested win- 
dow presently has a WMCLIENT owned frame win- 

40 dow as its parent; and 3) LOWER, meaning the 
requested window is neither the child of the root 
window nor a child of a WMCLIENT window. 

First, the current type of the requested window 
is determined, as is the future type of the window 

45 after reparenting (1201). The results of these deter- 
minations can be classified into one of three cases. 
Case 1 shown in Fig. 12 occurs when a LOWER is 
reparented to be a POPUP, a LOWER is reparen- 
ted to stay a LOWER or a POPUP is reparented to 

50 become a LOWER. Each of these indicates that 
there is no change in window management status. 
The new PM parent is set by calling PM WinSet- 
Parent (step 1203). Finally, the newly reparented 
window is moved to the position, relative to the 

55 parent origin, specified in the ReparentWindow re- 
quest (step 1204). 

Case 2 shown in Fig. 12 occurs when a LOW- 
ER or POPUP is reparented to be WIN- 
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DOWMANAGED, and indicates a change to the 
window management status of the requested win- 
dow, as the requested window is changed from 
being a nonmanaged (LOWER or POPUP) window 
to a managed (WINDOWMANAGED) window. Thus 
steps 1206-1208 in Fig. 12 involve converting a PM 
nonmanaged window to a PM managed window 
having a PM frame window. 

First, a pair of PM windows corresponding to 
the requested window and a frame window is cre- 
ated (step 1206) with processing similar to PM 
CREATEWINDOW, whose control flow was outlined 
in Fig. 10. WMCLIENT 540 will own the newly- 
created PM frame window, and the newly-created 
PM window of the requested window will replace 
the old PM window of the requested window speci- 
fied in the reparent window request. 

Children of the old requested PM window are 
then reparented to the newly-created PM window 
(step 1207), and the old requested PM window is 
then destroyed (step 1208). PM data for the old 
requested window need not be transferred to the 
newly-created requested window, since in the pre- 
ferred embodiment, display server 530 does not 
store window pixel data in a backing store. 

The conditions for case 3 shown in Fig. 12 are 
the inverse of case 2. Case 3 also indicates a 
change in window management status but occurs 
when a WINDOWMANAGED window is being re- 
parented to be a LOWER or POPUP. The status of 
the requested window is being changed from win- 
dow managed (WINDOWMANAGED) to nonwindow 
managed (LOWER or POPUP). The processing is 
similar to case 2. 

First, a single PM window is created with pro- 
cessing similar to PM CREATEWINDOW shown in 
Fig. 10 (step 1209). Children of the old requested 
PM windows are then reparented to the new re- 
quested window (step 1210). The old PM frame 
window and old requested PM window are de- 
stroyed by a call to PM WinDestroyWindow (step 
1211). Finally, the old X frame window is removed 
from the resource list with a call to FreeResource 
(step 1212). 

Fig. 13 and 14 shows additions needed to two 
routines for WMCLIENT 540 in the ConfigureWin- 
dow request code. 

In one routine, ChangeBorderWidth, processing 
must be performed to account for the fact that, in 
the X Window System, a window has two origins. 
The first origin is used to measure a window posi- 
tion relative to its parent and is located on the 
outside upper left hand corner of the window bor- 
der. The second origin is for drawing and it is 
located on the inside upper left hand corner of the 
window border. In PM coordinates, the width and 
height of a window grow by twice the change in 
border width. 



Flow diagram 1300 in Fig. 13 explains the 
change required. First, it must be determined 
whether the requested window requires window 
management functions (step 1301). This is prefer- 

5 ably done by testing whether the parent is owned 
by WMCLIENT. 

If the request does not require management, 
PM WinQueryWindowPos is called to get the cur- 
rent window width and height (step 1302). A new 

10 window width and height are calculated based on 
the current requested border widths (step 1303), 
and a new window origin is calculated (step 1304). 
The calculation of a new PM origin is required, 
even though the X window origin did not change, 

75 because of the upper lefthand corner location of an 
X window origin being different than the lower 
lefthand corner location of a PM window origin, as 
explained earlier. Finally, the new window height, 
width, and origin are set with a call to PM Win- 

20 SetWindowPos (step 1305). This call to PM Win- 
SetWindowPos performed for step 1305 will gen- 
erate a PM WM_MOVE event, as well as a PM 
WM_WINDOWPOSCHANGED event, because in 
step 1305 the window moves relative to the parent 

25 and changes size. 

If the request does require window manage- 
ment functions (step 1301) PM WinQueryWin- 
dowPos is called to get the current width and 
height (step 1306). A new width and height are 

30 calculated (step 1307), but a new origin is not 
calculated. A new origin is not calculated because 
the requested window will not move relative to the 
parent, which is the frame window. Finally, a new 
width and height are set with a call to PM Win- 

35 SetWindowPos, which will generate the PM 
WM_WINDOWPOSCHANGED event (step 1308). 

Fig. 14 contains flow diagram 1400 to illustrate 
the change to the routine MoveWindow, which will 
be called if the ConfigureWindow request is mov- 

40 ing a window relative to its parent. The added 
steps are performed to prevent clients from moving 
a frame window owned by WMCLIENT 540. Thus, 
in the preferred embodiment, managed windows 
can only be moved from the PM side via the PM 

45 user interface objects. 

In flow diagram 1400 first it is determined 
whether the requested window requires window 
management functions by testing whether the par- 
ent window is a WMCLIENT owned frame window 

50 (step 1410). 

The new PM window position is then calculated 
(step 1430). Finally, PM WinSetWindowPos is 
called to set the new PM position (step 1 440). 
MapWindow request processing has code in 

55 the routine MAPWINDOW to set the HASBEEN- 
MAPPED field of the X WindowRec structure, 
shown as 720 in Fig. 7, to true. This is done so that 
PM WM_MOVE and 
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WM_WINDOWPOSCHANGE events can be dis- 
carded until the window has been mapped at least 
once. 

MapWindow request processing has code to 
handle the case where a ChangeWindowAttributes 
request has changed the window management sta- 
tus of the requested window by adding or deleting 
the override-redirect attribute on the window. There 
will be a change in window management status if a 
child of a WMCLIENT-owned window has the 
override-redirect attribute, in which case the win- 
dow should go from a managed state to a non 
managed state; or if a child of the root window 
does not have the override-redirect attribute, in 
which case the window should go from a non- 
managed state to a managed state. If either of 
these two cases occur, a routine similar to Re- 
parentWindow is called with parameters to indicate 
that the root window is the new parent. 

The MapWindow request has code in the rou- 
tine pmMapWindow to map the PM frame window, 
if the window being mapped is window managed, 
rather than the PM window corresponding to the 
requested window. Mapping the PM frame window 
will map the WMCLIENT 540-owned frame and the 
requested window, and will generate a MapNotify 
event for each of the WMCLIENT 540-owned frame 
and the requested window. 

The UnmapWindow request has code in the 
routine pmUnmapWindow to unmap the PM frame 
window, if the window being unmapped is window 
managed, rather than the PM window correspond- 
ing to the requested window. Code additions for 
window unmap processing does not include setting 
the HASBEENMAPPED field to false, as that field 
indicates whether the window has been mapped at 
least once. Unmapping the PM frame window will 
unmap both the WMCLIENT 540-owned frame and 
the requested window, and will generate an Un- 
mapNotify event for each of the WMCLIENT 540- 
owned frame and the requested window. 

In processing the DestroyWindow request, a 
check is performed to determine if the window 
being destroyed has a WMCLIENT-owned window 
as parent. If so, a call to FreeResource is per- 
formed for the WMCLIENT-owned X window. Fur- 
ther, if a window-managed window is being de- 
stroyed, then a call to the PM routine Win- 
DestroyWindow is performed for the PM frame 
window instead of the requested window. The call 
to PM DESTROYWINDOW in this case will destroy 
both the frame window and the requested window. 
If the window being destroyed does not have a 
WMCLIENT-owned window as parent, the request- 
ed window is destroyed. 

In the X Window System, each window may 
have a number of named "properties," which are 
collections of data. A suggested feature, though not 



completely implemented in the preferred embodi- 
ment, involves the processing of properties in the 
routines ProcChangeProperty and Pro- 
cRotateProperties. If certain properties (such as 

5 WM NAME, WM_ICON_NAME, 

WM NORMALHINTS, WM_HINTS and 

WM TRANSIENT FOR) change because of a re- 
quest, certain PM routines would be called as a 
result. For example, if the WM_NAME property 

70 were to change and the requested window were 
being displayed, PM WinSetWindowText would be 
called to change the name in the requested win- 
dow's title bar. Another example would be when 
the icon_pixmap (a pixmap for a compact repre- 

75 sentation of a window, called an "icon"), which is a 
subcomponent of the WM_HINTS property, were 
to change and the requested window were to be in 
an iconic state, PM routines would be called to 
draw the new pixmap into the iconified window. 

20 

3. Processing Outgoing X Events 

In the X Window System, the X display server 
informs clients of the status of a window by send- 

25 ing X events. Normally, a window manager would 
be eligible to receive X events, as a window man- 
ager is just another client. In the preferred embodi- 
ment, however, X events that would normally be 
sent to a window manager client are not sent to the 

30 window manager client WMCLIENT 540 because 
WMCLIENT 540 does not set any event masks. 
Instead, display server 530 contains WMCLIENT 
540 X event processing code at places where the 
events are generated in display server 530. 

35 

4. Processing Incoming PM Events 

In the PM system, the PM server informs PM 
clients of the status of a window by sending PM 

40 events. In the preferred embodiment, X display 
server 530, being a PM client, receives PM events 
from host server 510. Fig. 15 shows a control flow 
diagram 1500 for processing the PM WM_MOVE 
event received from host server 510. 

45 There are at least two ways to receive the PM 
WM_MOVE event. The first way is that the user 
moves the window using one of the PM user inter- 
face objects. The second way is for a client, such 
as X client 533 connected to display server 530, to 

50 move, resize, or change the border width on the 
window with a ConfigureWindow request, which 
causes display server 530 to send a PM request to 
host server 510. This will in turn cause the host 
server 510 to issue a PM WM_MOVE event. 

55 Fig. 15 shows a control flow diagram 1500 for 
the routine HandlePMMoveMessage. PM Win- 
QueryWindowULong first is called to get a pointer 
to the X WindowRec structure of the moved win- 
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dow (step 1501). Second, it is determined whether 
the moved window has been mapped by testing 
the HASBEENMAPPED field, shown at 720 in Fig. 
7 (step 1502). 

If the window has never been mapped, normal 
processing is bypassed, as the PM WM_MOVE 
event will contain meaningless data. If the window 
has been mapped, it is determined whether the 
moved window requires window management func- 
tions (step 1503). This is done by determining 
whether the window has a WMCLIENT 540 owned 
window as its parent. 

If the window is being managed, Win- 
QueryWindowPos is called to get the frame win- 
dow's size and position (step 1504), and new X 
window coordinates are calculated and set in the 
frame window's X WindowRec (step 1505). The 
coordinates, called drawable.x, drawable.y, origin.x, 
origin.y, are set in portion 710 of the X WindowRec 
structure 700 (Fig. 7) of the parent window. 

The remaining processing is performed regard- 
less of whether the moved window requires man- 
agement. This processing includes calling PM Win- 
QueryWindowPos to get the PM coordinates for the 
moved window (step 1506). New coordinates for 
the X window are calculated (step 1507), and the 
new coordinates are set in the X WindowRec struc- 
ture 700 (step 1508). 

Next, it is again determined whether the win- 
dow requires window management functions by 
checking whether the window has a WMCLIENT- 
owned window as parent (step 1509). If the window 
is not window-managed, a ConfigureNotify X event 
is generated for the window (step 1 51 0). The Con- 
figureNotify X event is suppressed if the window 
has a WMCLIENT 540-owned window as parent 
because the processing of steps 1504 and 1505 
ensures that the moved window will not move rela- 
tive to its parent (the WMCLIENT frame window). 

Finally, ResizeChildrenWinSize is called with 
the change in the coordinates origin.x and origin.y 
for the window so the relative drawable positions of 
the window's children can be updated (step 1511). 

Processing for the PM 

WM_WINDOWPOSCHANGE event is similar to 
processing for the PM WM_MOVE event outlined 
in Fig. 15. One difference is that the steps of 
setting new coordinates (steps 1505 and 1508) also 
includes the steps of setting the width and height 
parameters for the window called drawable.width 
and drawable. height in portion 710 portion of the X 
WindowRec structure 700 (Fig. 7). Another dif- 
ference is that the ConfigureNotify event (step 
1510) is generated regardless of whether the 
moved window is managed, because the 
WM_WINDOWPOSCHANGE message may 
change the size of the window regardless of wheth- 
er the window is window managed. 



The PM user interface objects allow the user to 
"minimize" a window, causing the window to be 
displayed in a compact form called an "icon", or 
"restore" a window, causing the window to be 

5 displayed in the normal manner. Fig. 16 outlines 
processing for the PM WM_MINMAXFRAME 
event, which is generated when the user minimizes 
or restores a window. First, PM WinQueryWin- 
dowULong is called to get a pointer to the X 

w WindowRec structure of the affected window (step 
1605). It is determined whether the user has mini- 
mized or restored the window (step 1610). Pro- 
cessing of the PM WM MINMAXFRAME event 

involves calling PM WinSetWindowText using con- 

75 ventional X properties. Thus, if the user has mini- 
mized the window, the WM_ICON_NAME prop- 
erty, if defined, is used to call WinSetwindowText 
to set the window icon name field (step 1615). (A 
suggested feature, though not implemented in the 

20 preferred embodiment, is to read the WM HINTS 
property and to draw the icon pixmap into the 
minimized window, provided the property 
icon_pixmap in WM_HINTS is defined.) The X 
WindowRec structure is checked to determine 

25 whether WMCLIENT 540 is the owner of the in- 
dicated window, meaning that management is re- 
quired (step 1620). If management is required, 
WMCLIENT 540 sends an UnmapWindow request 
for the managed window and the frame window to 

30 display server 530, thereby causing display server 
530 to generate an UnmapNotify event for each 
window. 

If the user has restored the window, the 
WM_NAME property, if defined, is used to call 

35 WinSetWindowText to set the name in the win- 
dow's title bar (step 1630). The X WindowRec 
structure is checked to determine whether 
WMCLIENT 540 is the owner of the indicated win- 
dow, meaning that management is required (step 

40 1635). If management is required, WMCLIENT 540 
sends an MapWindow request for the managed 
window and the frame window to display server 
530, thereby causing display server 530 to gen- 
erate an MapNotify event for the window (step 

45 1640). 

The PM WM_SETFOCUS signifies a change 
in "input focus," meaning that a window is either 
acquiring or losing eligibility to receive keyboard 
input. The PM WM_SETFOCUS event can origi- 

50 nate either from PM, after the user changes the 
input focus with one of the user interface objects, 
or from an X client after an X client generates a 
SetlnputFocus request. 

Fig. 17 contains a control flow diagram 1700 

55 setting forth processing added to the routine 
DoFocusChange. First, a pointer to the X WIN- 
DOWREC for the X window corresponding to the 
PM window designated in the PM 
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WM_SETFOCUS event is obtained by calling PM 
WinQueryWindowULong (step 1701). 

Next, data bases are updated to reflect the 
change in input focus by calling DoFocusEvents to 
designate that the X window is gaining keyboard 
input focus and that no window is losing keyboard 
input focus, or that the X window is losing key- 
board input focus and that no window is gaining 
keyboard input focus, depending on whether the 
WM_SETFOCUS event designates that the X win- 
dow is gaining focus (step 1702). 

It is then determined whether management 
functions are required by checking whether the X 
window has a WMCLIENT-owned window as parent 
(step 1703). If management functions are not re- 
quired, the root window X_ROOT 601 (Fig. 6) is 
designated as the window for which input events 
are generated if no client solicits input events for 
the X window (step 1704). This designation is ef- 
fected by setting the FocusClassRec data struc- 
ture: focus-*revert = RevertToPointerRoot. 

If the window does require window manage- 
ment functions, then the WMCLIENT 540-owned 
window parent is designated as the window for 
which input events are generated if no client solic- 
its input events for the X window (step 1705). This 
designation is effected by setting the FocusClass- 
Rec data structure: focus-»revert = RevertToParent. 
The WMCLIENT 540-owned window is moved to 
the top of the stacking order by calling the sample 
server routines MoveWindowlnStack and Windows- 
Restructured (step 1706). 

D. CONCLUSION 

With the X display server window manager 
client according to the preferred embodiment, a 
server is provided which can be implemented using 
the support technology of an existing server. Cli- 
ents of the two servers can access the same 
graphics hardware while presenting a uniform user 
interface. Remote X Window Systems need not 
have knowledge of the type of host system in order 
to start a compatible manager. 

Additional advantages and modifications will 
readily occur to those skilled in the art. The inven- 
tion in its broader aspects is therefore not limited 
to the specific details, representative apparatus and 
illustrative examples shown and described. Accord- 
ingly, departures may be made from such details 
without departing from the spirit or the scope of 
applicant's general inventive concept. 

For example, there are alternative ways to im- 
plement the submitting step and the emulating 
step. One way would be to take advantage of the 
fact that the sample server executes one request at 
a time, and uses events to redirect requests to a 
window manager client. Instead of dispersing 



WMCLIENT 540 throughout the server, WMCLIENT 
540 could be made more modular. After a display 
server 530 receives a request from a user client, if 
the request is to be redirected to the window 

5 manager then display server 530 generates an 
appropriate event, thereby informing WMCLIENT 
540 of the request. 

The WMCLIENT 540 event handling procedure, 
in emulating a window manager's handling of an 

w event, may submit its own requests to display 
server 530 by calling the appropriate display server 
530 request processing routine directly. However 
some conditional statements that change the ex- 
ecution flow when the current request is from 

75 WMCLIENT 540 could be dispersed throughout the 
server. This would be needed because there are 
various places in the server where responding to a 
request as if it had come front a normal client 
would be inappropriate. 

20 Thus, WMCLIENT 540 could be a procedure 
composed of a set of interrelated computer instruc- 
tions organized as a callable module, and the part 
of display server 530 responsible for executing 
requests directly could be a different procedure. In 

25 such a design, it follows that the emulation of the 
management client by WMCLIENT 540 is per- 
formed at a different time than the execution of the 
functions in the graphics operation request directly. 
Further, the window manager need not reside 

30 in the same address space as the server and may 
instead be a separate process. Another possibility 
is that the window manager could be some ar- 
bitrary structure, not necessarily code. Instead, 
management functions could be performed by a 

35 data base or lookup table. 

In addition, although in the preferred embodi- 
ment the display server sends requests to the host 
server to communicate with the display, in an alter- 
native implementation the display server could 

40 communicate with the hardware more directly and 
the host server could communicate with the hard- 
ware by sending requests to the display server. 
Another possibility is that the display server could 
have a common interface to the hardware along 

45 with the host server. 

Claims 

1. In a computer system having a display server 
so to provide centralized display functions to a 
client, a method of responding to a request for 
graphics operations generated by the client, 
the request including at least one function, and 
the method comprising the steps, executed by 
55 the display server, of: 

receiving a request for a graphics opera- 
tion from the client; 

determining whether the graphics opera- 
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tion request requires performance of window 
management functions; 

submitting the graphics operation request 
to an emulated window management structure 
in the display server to perform any window 
management functions required by the graph- 
ics operation request; and 

executing the functions in the graphics op- 
eration request directly which do not require 
window management functions. 

2. A method according to claim 1, wherein the 
step of submitting the graphics operation re- 
quest to an emulated window management 
structure includes the substep of 

emulating, in the display server, a man- 
agement client for translating a graphics opera- 
tion request into a set of window management 
requests and for submitting the set of window 
management requests to the display server; 
and 

receiving the window management re- 
quests from the emulated management client. 

3. A method according to claim 2, wherein the 
performance of the step of emulating the man- 
agement client is interleaved with the perfor- 
mance of the step of executing the functions in 
the graphics operation request directly. 

4. A method according to claim 2, wherein the 
step of emulating the management client is 
performed at a different time than the step of 
executing the functions in the graphics opera- 
tion request directly. 

5. A method according to claim 2, wherein the 
computer system includes a display for a plu- 
rality of clients and 

wherein the step of emulating the manage- 
ment client includes the substep of 

generating a windowing interface for the 
display that is substantially the same for each 
of the clients. 

6. A method according to claim 5, wherein the 
computer system includes a host server coup- 
led to the display for generating a host win- 
dowing interface on the display; 

wherein the method further includes the 
step of 

sending messages from the display server to 
the host server to communicate with the dis- 
play; and 

wherein the step of generating the win- 
dowing interface includes the substep of 

generating the windowing interface to be 
substantially the same as the host windowing 



interface. 

7. A method according to claim 5, wherein the 
computer system includes a host server for 

5 sending requests to the display server to com- 

municate with the display and for generating a 
host windowing interface; 

wherein the step of generating the win- 
dowing interface includes the substep of 

70 generating the windowing interface to be 

substantially the same as the host windowing 
interface. 

8. A method according to claim 5, wherein the 
75 computer system includes a common interface 

to the display, and a host server for generating 
a host windowing interface and for sending 
messages to the common interface to commu- 
nicate with the display; 
20 wherein the method further includes the 

step of 

sending messages from the display server 
to the common interface to communicate with 
the display; and 
25 wherein the step of generating the win- 

dowing interface includes the substep of 

generating the windowing interface to be 
substantially the same as the host windowing 
interface. 

30 

9. A method according to claim 6, wherein the 
requests for graphics operations generated by 
clients includes requests to create a window, 

wherein the host server includes 
35 means for creating host windows for ap- 

pearing on the display, and 

wherein the substep of generating the in- 
terface to be substantially the same as the 
host windowing interface includes the substep 
40 of 

responding to a request to create a win- 
dow by sending a message to the host server 
to create at least one host window. 

45 10. A method according to claim 6, wherein the 
host server includes means for performing win- 
dow management functions; and 

wherein the substep of generating the win- 
dowing interface to be substantially the same 

so as the host windowing interface includes the 
substep of 

delegating selected ones of window man- 
agement functions in the graphics operation 
request to the host server. 

55 

11. A method according to claim 10, wherein the 
host server sends host events to the display 
server, and the host windowing interface in- 
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eludes user interface objects for manipulating 
window status, 

wherein the substep of generating the win- 
dowing interface to be substantially the same 
as the host windowing interface includes the 
substep of 

receiving a host event from the host server 
when the status of a window changes as a 
result of manipulation of one of the user inter- 
face objects. 

12. A method according to claim 1, wherein the 
computer system includes a display for a plu- 
rality of clients and a host server coupled to 
and sending host events to the display server, 
the host events including display status events, 
and wherein the method further includes the 
steps of 

receiving a host event from the host serv- 
er; 

translating the received host event into a 
set of display server events; and 

determining a corresponding set of clients 
to receive the set of display server events; and 

submitting the set of display server events 
to the corresponding set of clients. 

13. A method according to claim 12, wherein the 
step of submitting a request to the emulated 
management structure includes the substeps 
of 

emulating in the display server a client 
providing management functions; 

translating a selected one of the display 
server events in the set of display server 
events received from the display server into a 
set of management events; and 

determining a corresponding set of the cli- 
ents to receive the set of management events; 
and 

submitting the set of management events 
to the corresponding set of clients. 

14. A method according to claim 12, wherein the 
substep of submitting the set of display server 
events to the corresponding set of clients in- 
cludes the substep of 

determining whether one of the clients in 
the set of clients is the client providing window 
management functions; 

following a window management execution 
path if one of the clients in the set of clients is 
the client providing window management func- 
tions. 

15. A computer system for providing centralized 
windowing mechanisms to clients comprising: 

a display; 



client processor means for executing the 
clients which generate requests for graphics 
operations to be implemented on the display; 
and 

5 server processor means, coupled to the 

display and to the client processor means, for 
responding to the graphics operation requests 
generated by clients, the server processor 
means including 

w an emulated management structure for 

providing window management functions, 

means for receiving the graphics operation 
requests for graphics operations from the cli- 
ents, 

75 means, coupled to the receiving means, 

for determining whether the graphics operation 
requests for graphics operations requires per- 
formance of window management functions, 
means, coupled to the receiving means 

20 and to the determining means, for directly ex- 
ecuting the functions of the graphics operation 
requests which do not require window manage- 
ment functions, and 

means, coupled to the receiving means 

25 and to the determining means, for submitting 
to the emulated management structure the 
functions of the graphics operation requests 
which do require window management func- 
tions. 

16. A system according to claim 15, wherein the 
emulated window management structure in- 
cludes 

means for emulating a management client 
35 for providing management functions, the man- 
agement client emulating means including 

means for translating graphics requests 
into corresponding sets of window manage- 
ment requests, and 
40 means for submitting the set of window 

management requests to the server processor 
means. 

17. A system according to claim 16, wherein the 
45 means for emulating includes 

a first procedure composed of a first set of 
interrelated computer instructions; 
wherein the means for executing the graphics 
operation request directly includes 
50 a second procedure composed of a sec- 

ond set of interrelated computer instructions 
interspersed with the first set of computer 
instructions. 

55 18. A system according to claim 16, wherein the 
means for emulating includes 

a first procedure composed of a first set of 
interrelated computer instructions organized as 
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a callable module; 

wherein the means for executing the graphics 
operation request directly includes 

a second procedure composed of a sec- 
ond set of interrelated computer instructions. 5 

19. A system according to claim 16, wherein the 
means for emulating the management client 
includes: 

means for generating a windowing inter- w 
face on the display that is substantially the 
same for each of the clients. 



23. A system according to claim 20, wherein re- 
quests for graphics operations generated by 
clients includes requests to create a window, 
and the host server includes means for creat- 
ing host windows which may appear on the 
display, wherein the means for generating the 
user interface to be substantially the same as 
the host windowing interface includes 

means for responding to a request to cre- 
ate a window by sending a message to the 
host server to create at least one of the host 
window. 



20. A system according to claim 19, further com- 
prising a host server, coupled to the server w 
processor means and the display, including 

means for generating a host windowing 
interface; 

wherein the means for generating the win- 
dowing interface includes 20 

means for generating the windowing inter- 
face to be substantially the same as the host 
windowing interface, and 

wherein the server processor means in- 
cludes 25 

means for sending messages to the host 
server to communicate with the display. 

21. A system according to claim 19, further com- 
prising a host server for generating a host 30 
windowing interface including 

means for sending requests to the server 
processor means to communicate with the dis- 
play; and 

wherein the means for generating the win- 35 
dowing interface includes means for generating 
the windowing interface to be substantially the 
same as the host windowing interface. 

22. A system according to claim 19, further com- 40 
prising 

a common interface to the display; 

a host server including 

means for sending messages to the com- 
mon interface to communicate with the display, 45 
and 

means for generating a host windowing 
interface; 

wherein the means for generating the win- 
dowing interface includes 50 

means for generating the windowing inter- 
face to be substantially the same as the host 
windowing interface; and 

wherein the server processor means in- 
cludes 55 

means for sending messages to the com- 
mon interface to communicate with the display. 



24. A system according to claim 20, wherein the 
host server includes means for providing win- 
dow management functions; 

wherein the means for generating the user 
interface to be substantially the same as the 
host windowing interface includes 

means for delegating selected ones of win- 
dow management functions in the graphics op- 
eration request to the host server. 

25. A system according to claim 24, wherein the 
host server includes 

means for sending host events to the dis- 
play server, 

wherein the means for generating a host 
windowing interface includes 

means for generating user interface ob- 
jects for manipulating window status, 
wherein the means for generating the win- 
dowing interface to be substantially the same 
as the host windowing interface includes 

means for receiving a host event from the 
host server when the status of a window 
changes as a result of manipulation of one of 
the user interface objects. 

26. A system according to claim 15, further com- 
prising: 

an input/output driver; and 
a host server, the host server including 
means, responsive to the input/output dri- 
vers for generating host events; 

wherein the server processor means in- 
cludes 

means for receiving host events from the 
host server, and 

means, coupled to the host event receiving 
means for recognizing host events received 
from the host server, 

means, coupled to the recognizing means, 
for translating the host events into correspond- 
ing sets of display server events; 

means for determining a corresponding set 
of clients to receive each of the sets of display 
server events; and 
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30 



means, coupled to the recognizing means 
and to the determining means, for submitting 
the sets of display server events to the cor- 
responding sets of clients. 

5 

27. A system according to claim 26, wherein the 
emulated management structure includes: 

client emulation means for emulating a cli- 
ent providing management functions, the emu- 
lated client including w 

means for receiving the set of display 
server events from the means for submitting 
the set of display server events; 

means, coupled to the receiving means, 
for translating a selected one of the display 75 
server events in the set of display server 
events received from the server processor 
means into a set of management events; 

means, coupled to the translating means, 
for determining a corresponding set of the 20 
clients to receive the set of management 
events; and 

means, coupled to the corresponding set 
determining means and to the translating 
means, for submitting the set of management 25 
events to the corresponding set of clients. 

28. A system according to claim 26, wherein 
means for submitting the set of events to the 
corresponding set of clients includes 30 

means for determining whether one of the 
clients in the set of clients is the client provid- 
ing window management functions; 

means for following a window management 
execution path if one of the clients in the set of 35 
clients is the client providing window manage- 
ment functions. 
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